QA Wolf here! As you write new code it's important that your test coverage is keeping up.
Click here to request test coverage for this PR!

The latest updates on your projects. Learn more about Vercel for Git ↗︎

CodSpeed Walltime Performance Report

Merging #6343 will improve performances by 28.16%

_{Comparing nrc-uom-cmds (cc44d6c) with main (941911e)}

Summary

⚡ 7 improvements
✅ 85 untouched benchmarks

Benchmarks breakdown

Codecov Report

Attention: Patch coverage is 88.85496% with 73 lines in your changes missing coverage. Please review.

Project coverage is 85.34%. Comparing base (3d22f6c) to head (05815f1).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #6343      +/-   ##
==========================================
+ Coverage   85.16%   85.34%   +0.17%     
==========================================
  Files         108      108              
  Lines       46436    46437       +1     
==========================================
+ Hits        39547    39630      +83     
+ Misses       6889     6807      -82     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

As a user debugging after this change, I feel like I'm going to want to inspect values to know whether they've converted properly. I.e. what is the runtime value of this variable in some function? It used to be whatever number I passed in. But now it may have converted based on units in an intermediate function before being passed on.

As a user debugging after this change, I feel like I'm going to want to inspect values to know whether they've converted properly. I.e. what is the runtime value of this variable in some function? It used to be whatever number I passed in. But now it may have converted based on units in an intermediate function before being passed on.

Yeah! It's actually more complicated than that because numbers might be converted when they're passed to a function or when they're sent to the engine. I'm not really sure how to give users more insight. I really want to have values or at least types on hover but without access to program memory from the LSP or static checking, that isn't possible.

There's currently a log pane, but we don't use it. What do you think about adding a log() or println() function and returning it from execution?

CodSpeed Instrumentation Performance Report

Merging #6343 will not alter performance

_{Comparing nrc-uom-cmds (05815f1) with main (3d22f6c)}

Summary

✅ 54 untouched benchmarks

There's currently a log pane, but we don't use it. What do you think about adding a log() or println() function and returning it from execution?

There's already a log function in src/log.rs, but it doesn't use the log pane, it writes to the console (and it's dev-oriented rather than user-oriented). I think it's a good idea though. I wonder if we could include more numbers in the operation view thing?

Do you mean Operations in the Feature Tree? We've already been talking about showing variable definitions in there #5729 (comment). And the plan has been for a long time to be able to expand function calls to see inside them. We already record the arguments for function calls in Operations. We just haven't gotten to the UI for it yet.

For logs, I was thinking about something more explicit the way you might use println in Rust. Ideally it would appear as the KCL is executing, but a simple implementation would just return all the logs to be displayed at the end.

One complication is logs would need to be merged from parallel executed modules.

Do you mean Operations in the Feature Tree? We've already been talking about showing variable definitions in there #5729 (comment). And the plan has been for a long time to be able to expand function calls to see inside them. We already record the arguments for function calls in Operations. We just haven't gotten to the UI for it yet.

Yeah. I don't think we'd need to show variables, just the arguments to std functions and the values sent with the modelling commands. Though I guess variables might be useful for debugging (we already send variable values to the frontend from the interpreter, so that wouldn't be too hard, at least for variables outside of a function).

For logs, I was thinking about something more explicit the way you might use println in Rust. Ideally it would appear as the KCL is executing, but a simple implementation would just return all the logs to be displayed at the end.

Oh like a log function in KCL? Yeah, that would be really useful. Although how we present the data and syntax for interpolation would need a little design.

One complication is logs would need to be merged from parallel executed modules.

Yeah...

Cherry-picked #6431